今天把兩千個封包抓下來，想看清楚時戳打在封包的哪個位置。

兩千個封包，一個都沒掉

先講結果：

exanic-capture: received=2000 corrupt=0 aborted=0 hw_lost=0 sw_lost=0 other=0

做法三句話講得完：

• exanic-measure 從 port0 發封包
• exanic-capture 在 port1 把線上跑過去的東西錄成 pcap 檔
• tcpdump -r 把錄下來的讀回來看

一邊發一邊錄，所以兩支工具要同時用同一張卡。我本來以為這裡會撞車，結果沒有，一個在 TX 一個在 RX，互不干擾。

重點在 hw_lost 跟 sw_lost 這兩欄，下面我寫成 hardware_lost 跟 software_lost，比較好讀。發兩千、收兩千，這兩個都是零，也就是擷取的過程一個封包都沒漏掉。
線速擷取的意思就是 每一個封包都有時戳，不是抽樣，也不是「大概都抓到了」。 一般軟體抓包在流量大或主機忙的時候會漏，麻煩的是它漏了不一定會講。硬體擷取把「漏了幾個」單獨列成一欄擺在你面前。
這個差別在排查的時候很要命。軟體抓包沒抓到某個封包，你分不出是封包真的沒來、還是你沒抓到。這兩件事要查的方向完全相反。

時戳有九位小數，tcpdump 只顯示六位

讀出來的第一個封包時戳長這樣：

8114353832876 ns

換算成秒是 8114。因為我沒有把卡上的時鐘跟外面校時。工具的說明其實有寫，-H 那行後面跟著一句 refer to documentation on how to sync clock，我略過了。
而沒校時的硬體時戳就只是一支碼表，它可以很精確地告訴你「這兩個封包差多久」，但它答不出「這是幾點幾分幾秒收到的」。如果要把網路的時戳跟主機上的 log 對起來看，那才需要真正的時間，而那是另一套工作。

麻煩的是 tcpdump 只印六位小數：

8114.353832
8114.353834

照這個相減，前兩個封包差 2000 奈秒，但檔案裡的真值是 1908：

file 說那個 pcap 本身就是奈秒格式，而 1908、1548、1444 沒有一個是 1000 的倍數——只有微秒精度的話，這一欄只會出現 1000、2000 這種數字。三位小數躺在檔案裡，是印出來的時候被切掉的。切掉的不是零頭，這個間隔差了將近百分之五。

這件事值得記住：顯示工具沒印給你的東西，不代表資料裡沒有。

那張摘要是怎麼長出來的

昨天貼的那張統計摘要，中位數多少、p99 多少，那些數字不是工具憑空給的。把原始 CSV 倒出來看就知道：

發出去的時候記一個時戳，收回來的時候記一個時戳，相減就是那一欄。整整一千筆逐筆對過，沒有一筆對不上。
摘要只是把這一千個數字排序之後挑幾個位置報給你。你拿到的每一個統計值，背後都有一份可以自己重算的原始資料，這件事在後面談調校驗證的時候會一直用到。

開頭那句話，今天只答得出一半

「看時戳打在封包的哪個位置」——今天證明得了每個封包都有時戳、是奈秒解析度、而且相減就是延遲。

但打在開頭還是結尾，今天的資料分不出來。 這次從頭到尾都是 64 bytes 的封包，長度沒變過。時戳不管打在哪一端，量出來的數字都一樣。

要分辨得換封包長度：如果時戳打在開頭，封包變長延遲不會變；打在結尾，封包變長延遲就要跟著變。 這件事明天做。

兩個計數器要盯

hardware_lost 跟 software_lost 直接就是監控項，門檻是零。

不是「累積超過多少才告警」，是從零變非零就告警。這個數字在健康的環境本來就該是零，兩千個封包裡出現一個，就代表有東西該處理了。
兩個掉的位置不一樣，要查的方向也不一樣：

hardware_lost 非零   -> 網卡那一側沒收進來
software_lost 非零   -> 收進來了，但讀取的程式沒跟上

這兩欄的確切定義我還沒去翻文件，今天兩個都是零，也就沒有機會弄清楚。但名字已經把該往哪查講明白了：
一個是卡的事，一個是程式的事。搞混這兩個數值，就會把主機的問題當成網路的問題查。

所以 做任何抓包分析之前，先看這兩個數字，它們在非零的時候，你手上那份 pcap 本身就是不完整的，在上面數封包、算間隔、找遺漏，結論都不能用。

明天做直連校正，量儀器自己的延遲，順便回答今天沒答完的那半句。